Today, complex e-business applications (for example, the e-banking applications) are manytimes deployed in multiple tiers (including web server, application server, and database server for example). End-users' experience long response delay to get from an e-business application the response to their request. And both end-users and the owner of the e-business application do not know the source of this delay. In fact, the there are often many potential sources of this delay, such as the network latency or other network problems, the web server latency or other server problems, the application server latency, and/or the database server latency.
Some e-business applications are quite important for end-users and application owners. To these e-business applications, therefore, all problems must be identified, located and fixed before things get worse.
To application owners, application profiling is a good way to find and fix all problems before things get worse.
As is well known to those skilled in the art, there are two different types of application profiling solutions: one is log based, the other is network based.
Each of them has their own pros and cons.
As those skilled in the art know, a major problem in network-based multi-tier application profiling is there is no way to correlate interactions, which occur due to one or a set of specific events, between adjacent tiers in an actual environment, so that only statistics-based end-to-end analysis (which cannot reflect said specific events) other than more precise non-statistical end-to-end analysis can be provided for said specific events.
Considering an exemplary actual environment as shown in FIG. 1, in this figure, an e-business application is deployed in multiple tiers including a load balancer 110, a web server 120, an application server 130, and a database server 140.
Clients 160-1, 160-2, . . . , 160-N send various requests to load balancer 110 and receive responses of corresponding requests therefrom.
It should be understood that a network, which might be a local area network, a metropolitan area network, a wide area network, or a combination thereof, may be included between clients 160-1, 160-2, . . . , 160-N and load balancer 110, between load balancer 110 and web server 120, between web server 120 and application server 130, as well as between application server 130 and database server 140. For example, the network may be an 802.x-based local area network.
To correlate interactions, which occur due to one or a set of specific events, between adjacent tiers, a straightforward and simple way is to know the characteristic of each interaction. For example, each interaction is about the user “user 1.” But in a multi-tier environment, the characteristic would be lost during the processing procedure. For example, between application server 130 and database server 140, the interaction might be the database request structured query language (SQL) statement “select * from accountDB where cardID=80020005123456789” where there is no “user 1” in the interaction.
Therefore, though in network-based multi-tier application profiling, all interactions between adjacent tiers can be obtained by interaction obtaining means that includes, for example, switch, router and other device, interaction obtaining means can easily obtain interactions between web server 120 and application 130 and interactions between application server 130 and database server 140 by leveraging some existing technologies, such as switch port mirroring, fiber splitter, cable tap, etc, however, in multi-tier case, characteristic of interactions would be lost during the processing procedure, and in the actual environment, the number of interactions between tiers is huge, therefore, it is difficult to correlate interactions, which occur due to one or a set of specific events, between adjacent tiers, and more precise non-statistical end-to-end analysis cannot be provided for the specific events.